We'll begin our discussion of the tools and best practices around troubleshooting
federation and federated delegation in Exchange Server 2010 by looking
at the federation trust, then move on to organization relationships and
Calendar and Contacts sharing, and finish up by examining RMS
federation.
|
Devin L. Ganger
Solutions Architect, Trace3, USA
In Exchange Server 2007,
sharing calendar data with other Exchange Server 2007 organizations was
on a per-foreign organization basis, and the controls around it were
not very granular. This meant that your Client Access servers had to
talk to their CA servers and you needed to either establish a forest
trust and grant permissions to the other forest's CA servers (to get
detailed per-user free/busy information), or set up a separate user in
your forest for the foreign forests to use and provide that user with
these credentials (to get default per-org free/busy data). Aside from
the large amount of effort and troubleshooting involved, this process used user accounts
for authentication, so it worked well with ISA Server's or TMG's Web
listener. During the initial Exchange 2010 deployment at a previous
employer, we published Exchange 2010 with ISA 2006 SP1 configured to
pre-authenticate users with FBA (Forms-Based Authentication) using a
single Web listener.
However, here's the problem: with federated delegation in Exchange Server 2010, you're using SAML tokens—not user accounts—to
authenticate against IIS for EWS calls. ISA Server doesn't know how to
validate SAML tokens, so the incoming requests can't be authenticated
and passed on to the Exchange Server 2010 CA server. The end result is
that we couldn't get a proper sharing relationship set up and you can't
federate calendar data.
When we knew what the
problem was, fixing it involved modifying the OWA and ECP virtual
directories on all of our Exchange Server 2010 CA servers to perform
FBA, then modifying the Web listener on our ISA Server to disable
pre-authentication. Finally, we needed to modify the authentication
settings for each of the ISA publishing rules for ActiveSync, Outlook
Anywhere, and OWA to set them to No Delegation, But Client May
Authenticate Directly, and to revise the Users settings from All
Authenticated Users to All Users. Revising the Users settings is
important; without this, ISA won't pass any connections on to the CA
servers. You may also need to verify that the authentication settings
of your other Exchange virtual directories are valid; many
organizations will allow basic authentication between ISA and their CAS
servers, but require NTLM or Windows Integrated from external clients
to ISA.
If you're using multiple Web
listeners to publish Exchange 2010, then your steps may be different.
The federated delegation feature requires direct access to the EWS vdir
on your CAS servers, and EWS is typically published on ISA and TMG as
part of the Outlook Anywhere rules. If you publish those using a
separate Web listener—which will require a separate IP address, FQDN,
and SSL certificate—you can simply disable pre-authentication for that
Web listener, but still allow it on your OWA, ECP, and EAS directories.
Calendar sharing and
ISA Server/TMG FBA pre-authentication are both wonderful features, but
at this point they are not compatible.
|
1. Troubleshooting the Federation Trust
The foundation behind all aspects of federated delegation is the federation trust with the Microsoft Federation Gateway, so we'll start by looking at that.
The EMS cmdlet named Test-FederationTrust
verifies several aspects of your federation with the Microsoft
Federation Gateway. This cmdlet must be run from either an Exchange
Server 2010 Hub Transport or Client Access server, and it does the
following:
It establishes a
connection to the Microsoft Federation Gateway; this test verifies the
communication between the Microsoft Federation Gateway and Exchange
Server 2010 is functional. The
local certificates designated for federation are verified for validity
to ensure that they can be used with the Microsoft Federation Gateway.
If the certificates are deemed to be not valid, you can obtain details
on the certificates by using the Get-FederationTrust cmdlet, discussed later in this section. The cmdlet requests a security token from the Microsoft Federation Gateway to verify that tokens can be properly retrieved and used.
Note:
The Test-FederationTrust
cmdlet uses a mailbox in the organization for testing, and requests a
security token for that mailbox. You can use a mailbox specified with
the -UserIdentity
parameter; if no mailbox is specified the default test mailbox is used.
If no mailbox is specified and the default test mailbox is not present,
the Test-FederationTrust
cmdlet fails. The default test mailbox must be created beforehand with
the New-TestConnectivityUser.ps1 script found in the Scripts folder of
the Exchange installation.
Another useful cmdlet is Test-FederationTrustCertificate.
This cmdlet verifies the distribution of the certificates used for
federation on all Hub Transport and Client Access servers, and should
be run prior to setting the Next certificate as the Current certificate
with the Set-FederationTrust cmdlet or the Manage Federation Wizard in the EMC. No parameters need to be specified with the Test-FederationTrustCertificate
cmdlet. You can also verify the distribution of the federation
certificates to all CA and Hub Transport servers on the Manage
Federation Certificate page of the Manage Federation Wizard by clicking Show Distribution State, as shown in Figure 1.
You can also use numerous Get- cmdlets to retrieve information useful for troubleshooting various aspects of your federation configuration:
The Get-FederatedOrganizationIdentifier
cmdlet retrieves the federated organization identifier for your
organization as well as related details such as federated domains
(accepted domains), organization contact, and status. If the Get-FederatedOrganizationIdentifier cmdlet is run with the -IncludeExtendedDomainInfo
parameter, the MFG is queried for the status of each accepted domain
that has been federated. The status of these domains is returned in the
Domains property of the cmdlet's output. This cmdlet is useful in troubleshooting issues with different accepted domains in your environment. The Get-FederationTrust cmdlet is used to retrieve information on your federation trust with the Microsoft Federation Gateway. When run as Get-FederationTrust | fl, the following information is returned: The AppID and application URI for the trust. You can use this to verify that the TXT
resource record created in your external DNS when the trust was
established is correct. The current, next, and previous certificates configured for the federation
trust, including their subject, issuer, and issue and expiry dates. The token issuer current and previous certificates from the MFG. The distinguished name of the federation trust object in Active Directory. WhenChanged and WhenCreated date/time parameters for the federation trust.
You can use the Set-FederationTrust cmdlet to manage your organization's certificates used for federation. You can also use Set-FederationTrust to refresh the metadata from the Microsoft Federation Gateway when you run it with the –RefreshMetadata parameter as part of your troubleshooting process.
|
Gary A. Cooper
Senior Systems Architect, Horizons Consulting, Inc., USA
At some point after you have deployed your federation
trust, one of two certificate issues will present themselves. Either
the Microsoft Federation Gateway Certificate will expire or your
federation certificate will expire. If the first event occurs, the
people responsible for the Microsoft Federation Gateway will manage
certificate updates for the MFG. However, your CAS servers may not
always update their version of the metadata that they obtain from the
MFG. Typically, you will see Event ID 2009 from Source: MSExchange
Certificate Deployment with a description indicating that the
certificate will be expiring in less than 15 days.
To remove this warning, you can try the following cmdlet in the EMS:
Set-FederationTrust MyFederationTrust -RefreshMetadata'.
On the other hand, if it is your
certificate that is about to expire, or if it has expired and you now
have the updated certificate, you will need to update it within the
Federation framework by telling the Microsoft Federation Gateway to
begin using your new certificate. This is done with the following
commands. The first command tells your CAS/Hub servers to register your
new certificate as the next one to use with the MFG:
Set-FederationTrust -Identity <your Trust Name here> -Thumbprint <Your
new Certificate Thumbprint here>
The next command tells your
CAS/Hub and the MFG to roll to the next certificate and to stop using
the older original certificate. Before you issue this command, it is
vital that this is the correct certificate and that the new certificate
has replicated to ALL CAS/Hub servers in your organization. This is a
one-way command and is not easily undone:
Set-FederationTrust <your Trust Name here> -PublishFederationCertificate
To verify the certificate that is currently in use, run Get-FederationTrust |fl *cert* and look for the OrgCertificate, OrgNextCertificate, and OrgPrevCertificate values,
which will show you the currently used, next in line to be used, and
previously used certificates respectively. Pay particularly close
attention to the Thumbprint
and time stamps (shown as Not Before and Not After). Many times I have
seen expired certificates being used or ones that haven't yet started.
This is not only true for your certificates but also for those that
your CAS/Hub servers are using from the MFG.
Finally, many
organizations have had difficulty with managing the federated trust
relationship simply because the CAS/Hub server they were working with
it on did not have direct Internet access. To manage the certificate
and trust relationship with MFG, the CAS/Hub server must have access to
the Internet over TCP ports 80 and 443.
|
|
